home *** CD-ROM | disk | FTP | other *** search
Text File | 1989-09-01 | 1.8 KB | 35 lines | [TEXT/GEOL] |
- Item 9312268 31-Aug-89 10:11
-
- From: CHESLEY1 Chesley, Harry,APL
-
- To: MACAPP.TECH$ MACAPP Tech
- D2336 Medic, Darrell Styner,PRT
-
- Sub: Re: MacApp Terminal Driver?
-
- Yes, using a co-handler is workable. The best way is probably to define a
- serial port object, which installs itself, and then has methods to define what
- an input "block" is (i.e., one character, up to a carriage-return, etc., etc.
- -- it can be subclassed for really unusual conditions). You can either subclass
- this to implement the application-specific receiver, or have a block-handler
- object that is sent a message when a block comes in.
-
- As to 9600: You can put a large buffer on the serial port (I usually use 10K,
- since that's a lot for most serial connections, which seldom deal with things
- larger than a glass-TTY screen (about 2K), but it isn't all that much as a
- percentage of a normal MacApp program). After that, it depends on how big of a
- chunk your program uses to manipulate the input. If it's drawing a character at
- a time on the screen (including scrolling), it may not keep up with 9600. If
- it's just saving the whole input block in memory, then there's no problem. (The
- other way to say that is that if the per character overhead is small enough,
- you can keep up with 9600; if it isn't, you can't. That overhead depends a lot
- on the size block you process coming from the serial port.) If you can keep up
- with the data rate, then you don't need to think about any sort of flow
- control, which can make things much more complicated.
-
- You should also take a look at the Communications Toolbox, available in beta
- form from APDA. It covers a much broader base than the traditional serial
- driver, and may have additional features that are useful (like terminal
- emulation, for example).
-
-